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(54) Procede et systeme d'administration de reseaux et de systernes 



(57) La presente invention concerne un procede et 
un systeme d'administration de reseaux etde systernes. 

Le procede d'administration d'un reseau est carac- 
terise en ce qu'il comprend au moins un sous-adminis- 
trateur (COACH) situe dans I'arbre de contenance entre 
un administrateur principal (AD) et !es equipements du 
reseau, le sous-administrateur etant localise sur le re- 



seau local d'entreprise (RLE), administrant un sous-re- 
seau et comprenant differents modules qui communi- 
quent entre eux et avec un administrateur principal (AD) 
par ('intermediate d'un noyau (N), les modules interro- 
geant les equipements du sous-reseau et recevant les 
alarmes lancees par les agents (snmp) fonctionnant sur 
les equipements du sous-reseau. 



FIG. 3 




a, 

yj 



Printed by Jouve. 75001 PARIS (FR) 



BNSDOCID: <EP 0951 155A1_I_> 



EP0 951 155A1 

Description 



10 



15 



20 



25 



30 



35 



40 



SO 



55 



les alarmes d'un reseau et d'effectuer des oJ^J^^T -, ' 1 d8p ° rte et permet de c °ncentrer 

Ma... SM Monitor 6000 

Place importante en memoire. Deplus aujourd'hui uZ™Z™hT* I 1 Processing Unrt) et prend une 

en grand nombre. Or, SM MonKoMWOO ne e ^Pnses a besoin de gerer des petits reseaux 

inexploitable sans cet outil ettectuer qu avec la plate-forme "System View" et est 



[0005] Une demiere solution, propos§e Dar la societP "RMr cr,ft..,or»» „ •. 

de surveiller un ensemble d'agents appe^aoen^ pltra^lT la ? T ™ m ° dU ' e de contr6le q ui P*™* 

assurer un role d'administrateur vis-a-vis d'aaents L'so^nt Pa tr«i tZ* T ° qu,pements - elle n es » pas concue pour 
qu-une source deformations et nL s Jimttf n« T ** IOC § les sur une machine ' 11 "'est 

par .angage inte^tf C ° nS ° mmatrlCe de tem P s et *« ^ystemes cibles a cause de la technologie 



BNSDOCID: <EP 0951155A1_I_> 



2 



EP0 951 155 Al 



dynamiquement prises en compte au cours de Pexploitation, sans intervention de foperateur. Enfin, invention permet 
une diminution de la charge de traitements d'informations au niveau du controle. 

[0007] Ce but est atteint par le fait que le procede d' administration d'un reseau comprend au moins un sous-admi- 
nistrateur (COACH) situe dans I'arbre de contenance entre un administrateur principal (AD) et les equipements du 
reseau, le sous-administrateur est localise sur le reseau local d'entreprise (RLE), administre un sous-reseau et com- 
prend differents modules qui comrnuniquent entre eux et avec un administrateur principal (AD) par rintermediaire d'un 
noyau (N), les modules interrogeant les equipements du sous-reseau et recevant les alarmes lancees par les agents 
(snmp) lonctionnant sur les equipements du sous-reseau, le procede etant compose de plusieurs etapes : 

une 6tape pendant laqueile un module de decouverte (MD) interroge tous les equipements (ET) possibles du sous- 
reseau, 

une etape de recherche de domaine par le module de decouverte (MD), lorsqu'un equipement repond a I'interro- 
gation (SNMP), 

une etape pendant laquelie le module de decouverte (MD) envoie une notification a un module de configuration 
des modeies (MCM) lui indiquant I'adresse internet (IP) de I'equipement decouvert et le domaine auquel I'equipe- 
ment decouvert appartient, 

une etape pendant laqueile le module de configuration des modeies (MCM) notifie a un module de calcul d'indi- 
cateurs (MCI), I'indicateur a instancier sur I'equipement et a un module de filtrage d'alarmes (MFA) !e modele de 
filtre a instancier sur I'equipement. 

[0008] Selon une particularite de ('invention, le procede d'administration d'un reseau est caracterise en ce qu'a cha- 
que nouvelle etape de decouverte des equipements du sous-reseau, le module de decouverte (MD) met a jour les . 
bases de donnees du noyau (N) et du module de configuration des modeies (MCM) contenant la liste des equipements 
et de leurs domaines. 

[0009] Selon une autre particularite, toutes les alarmes emises par les differents modules sont envoyees a I'admi- 
nistrateur principal (AD) via le module de securisation d'alarmes (MSA), ladite alarme etant accompagnee d'un mes- 
sage d'envoi destine au serveur du module de securisation d'alarmes (sMSA). 
[0010] Selon une autre particularite, le procede d'administration d'un reseau est compose: 

d'une etape de reception de ('alarme par I'administrateur principal (AD) et de reception dudit message d'envoi par 
le serveur du module de securisation d'alarmes (sMSA)., 

d'une etape d'envoi d'un message de confirmation de reception par le serveur du module de securisation d'alarmes 
(sMSA) au client du module de securisation d'alarmes (cMSA), 

d'une etape de reception du message de confirmation de reception par le client du module de securisation d'alar- 
mes (cMSA), 

d'une etape de mise a jour des instances d'alarmes stockees dans le module de filtrage d'alarmes (MFA). 

[0011] Selon une autre particularite, lorsque le client du module de confirmation d'alarmes (MCA) n'a pas recu le 
message de confirmation de reception, il renvoie, apres un temps determine, I'alarme a I'administrateur principal (AD), 
I'alarme etant accompagnee d'un message d'envoi destine au serveur du module de securisation d'alarmes (sMSA). 
[0012] Selon une autre particularite, lorsque le module de calcul d'indicateurs (MCI) ou le module de decouverte 
(MD) n'obtient pas de reponse a une requete envoyee a un equipement du sous-reseau, le module de calcul d'indica- 
teurs (MCI) ou le module de decouverte (MD) envoie un message a un module chien de garde (MCG), le module chien 
,de garde (MCG) interrogeant I'equipement suppose disparu et attendant de maniere plus Iqngue, une reponse. 
[0013] Selon une autre particularite, lorsque, apres un temps determine, le module chien de garde (MCG) n ! obtient 
pas de reponse de I'equipement suppose disparu, I'equipement est supprim6 de la base de donnees du noyau (N), 
de la base de donnees du module de decouverte (MD) et de la base de donnees du module de configuration des 
domaines (MCM), le module chien de garde (MCG) envoyant une alarme a I'administrateur principal (AD), lui indiquant 
la disparition de I'equipement, I'alarme etant percue par I'administrateur comme provenant de I'equipement et envoyee 
en utilisant le module de securisation. 

[0014] Selon une autre particularite, lorsque le module chien de garde (MCG) obtient une reponse de I'equipement 
suppose disparu, il demande la redecouverte des domaines, si la demande a ete ernise par le module de calcul Vin- 
dicate ur. - ' 

[0015] Un autre but de I'invention est de foumir un systeme d'administration de reseaux et de systemes. 
[0016] Ce but est atteint par le fait que ce systeme d'administration d'un reseau par un administrateur principal 
communiquant avec des equipements (ET) a travers un reseau grande distance (WAN) et des reseaux locaux d'en- 
treprises (RLE) est caracterise en ce qu'il comprend au moins un sous-administrateur (COACH) localise sur le reseau 
local d'entreprise (RLE) et administre par I'administrateur principal (AD). Le sous-administrateur (COACH) comportant 
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des moyens d'interroger les equipements du reseau local d'entreprise (RLE), defiltrer et de stocker les alarmes lancees 
par les agents (snmp) fonctionnant sur les equipements du reseau, des moyens de securiser les alarmes envoyees a 
I'administrateur principal (AD) et un moyen de dialogue avec I'administrateur principal et entre les differents moyens. 
[0017] Selon une particulate de {'invention, le moyen de dialogue est constitue d'un noyau (N) dialoguant avec 
I'administrateur principal (AD) et permettant le dialogue entre les differents modules composant ledit systeme, Selon 
une autre particularite, les moyens d'interroger les equipements du reseau local d'entreprise (RLE), de filtrer et de 
stocker les alarmes lancees par les agents (snmp) fonctionnant sur les equipements du reseau sont constitues 

- d'un module de decouverte (MD) decouvrant les equipements (ET) du sous-reseau a administrer et classant lesdits 
equipements dans des domaines.en fonction des types d'agents qui y sont installes. Ce module de decouverte 
amplifie la fonction de decouverte de I'administrateur central, par une precision accrue, une decouverte plus rapide 
et une economie considerable en bande passante, 

- d'un module de configuration de modeles (MCM) comportant des modeles de filtre d'alarmes et des indicateurs 
pouvant etre instancies sur les equipements du sous-reseau, chaque indicateur etant associe a une periode d'in- 

1 $ terrogation, 

- d'un module de calcul d'indicateurs (MCI) calculant le resultat de Implication d'un indicateur a un equipement, 
I'indicateur etant defini pour le domaine auquel I'equipement appartient, le resultat de cette application etant com- 
pare a une valeur seuil ne devant pas etre depassee un certain nombre de fois, pendant un certain laps de temps. 

- d'un module de filtrage d'alarmes (MFA) recevant les alarmes envoyees par les agents (snmp) fonctionnant sur 
les equipements du sous-reseau, puis, selectionnant une partie desdites alarmes a I'aide d'un filtre defini pour un 
domaine donne, lesdites alarmes selectionnees etant re-emises vers I'administrateur principal (AD), 

[0018] Sejon une autre particularite, les moyens de securiser les alarmes envoyees a I'administrateur principal (AD) 
sont constitues : 
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- d'un module de chien de garde (MCG) qui, lorsqu'un module le lui demande, verifie ('existence d'un equipement 
par renvoi repete d'appels, si I'equipement disparu n'a pas repondu a un nombre predefini d'appels, ledit module 
chien de garde (MCG) envoie une alarme a I'administrateur principal (AD) qui sera percue par ce dernier comme 
provenant de I'equipement disparu, 

30 - d'un module de securisation d'alarmes (MSA) fonctionnant selon le mecanisme client-serveur, le client (cMSA), 
lors de renvoi d'au moins une alarme a i'administrateur, attendant un message de confirmation du serveur (sMSA) 
localise sur I'administrateur principal (AD), ledit serveur (SMSA), apres reception dudit message d'envoi, envoyant 
un message de confirmation de reception au client (cMSA), le client renvoyant I'alarme et un autre message d'envoi 
a administrates lorsque, apres un temps determine, le message de confirmation de reception n'est pas recep- 

35 tionne par le client. 

[0019] Selon une autre particularite, lorsque la valeur seuil est depassee un certain nombre de fois pendant un 
certain laps de temps, le module de calcul d'indicateurs (MCI) emet une alarme vers I'administrateur principal (AD), 
ladite alarme etant pergue par I'administrateur principal comme etant emise par Tequipement dont I'instanciation a eti 
40 effect uee. 

[0020] Selon une autre particularite, un indicateur est une equation appliquee a des instances d'objets d'une base 
de gestion d'informations (MIB), les instances etant obtenues par une interrogation des agents (SNMP) fonctionnant 
sur chacun des equipements du sous-reseau. 

[0021] Selon une autre particularite, le resultat d'un indicateur et/ou une liste des alarmes envoyees peut etre stocke 
4S dans un fichier archive sur le disque dur. * 

[0022] Selon une autre particularite, le parametrage des filtres d'alarmes s'eff ectue soit par un fichier ^initialisation 
soit via le protocole snmp. 

[0023] Selon une autre particularite, les alarmes a envoyer sont accumulees par le module de confirmation d'alarmes 
afin de les envoyer groupees, par paquet, a une frequence donnee. 

[0024] Selon une autre particularite, un modele de filtre d'alarmes contient une description de I'alarme a reconnaTtre 
et un nombre maximal d'occurrence d'alarmes avant lequel une autre alarme est emise vers I'administrateur principal 
(AD), si ledit nombre maximal d'occurrence d'alarmes est re?u pendant une certaine periode. 

[0025] Selon une autre particularite, les differents modules interrogent le noyau (N) pour initialiser leurs parametres 
de fonctionnement. 

[0026] Selon une autre particularite, le noyau (N) gere une base de donnees contenant toutes les instances de la 
base de gestion d'informations (MIB), ledit noyau comportant au moins deux supports (sockets) de communication et 
une interface commune de gestion de la communication avec les modules. 

[0027] Selon une autre particularite, les parametres ^initialisation du module de decouverte (MD) comportent la 
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periode espacant deux decouvertes, le nombre minimum de systemes a decouvrir et le masque du protocole internet 
(IP) determinant I'etendue du reseau a decouvrir 

[0028] - Selon une autre particularite, un equipement (ET) decouvert est classe dans un ou plusieurs domaines en 
fonction de ses reponses aux interrogations effectuees sur chaque ensemble d'instances d'objets de la base de gestion 
s d'informations (MIB) definissant un domaine. 

[0029] D'autres particulates et avantages de la presente invention apparaitront plus clairement a la lecture de la 
description ci-apres faite en reference aux dessins annexes dans lesquels : 

la figure 1 represente un exemple d'implementation du procede d'administration de deux sous-reseaux, 
10 - la figure 2 represente I'architecture du systeme d'administration, 

la figure 3 represente un exemple d'implementation du procede d'administration de n sites, 
la figure 4 represente un systeme d'administration classique. 

[0030] La presente invention propose un procede et un systeme de gestion de reseaux totalement parametrables a 
is distance via un protocole standard : ie protocole SNMR Comme le montre la figure 1, le systeme d'administration de 
reseau est compose d'un administrateur (AD1 ) et d'au moins un sous-reseau local (RLE1 , RLE2) relie a un agent 
ouvert central pour une administration concentree (COACH, Central Open Agent for Concentrated Handling). Le sous- 
administrateur (COACH 1 ) agit a un niveau intermediaire d'administration. Situe sur le reseau local d'entreprises 
(RLE1), il permet de limiter le flux d'administration entre I'administrateur principal (AD1) et les equipements (ET) du 
20 reseau (RLE1 ). II est percu par les equipements du reseau comme un administrateur et par I'administrateur comme 
un equipement. 

[0031] Le sous-administrateur (COACH), tel que represente en figure 2, comporte un ensemble de processus aussi 
appeles "modules" qui dialoguent les uns avec les autres et avec I'administrateur principal (AD) par ('intermediaire d'un 
processus central aussi appele "noyau" (N). Les dialogues entre les differents modules se font par un support (socket) 

25 portable et standard. Chaque module est dedie a une fonction precise. 

[0032] Le module central ou noyau (N) a deux fonctions principals. D'une part, il dialogue avec I'administrateur 
(AD) et d'autre part, il gere le dialogue entre les differents modules composant le sous-administrateur (COACH). En 
effet, le noyau (N) repond au dialogue (snmp), lorsque le sous-administrateur (COACH) est interroge ou configure par 
I'administrateur. II existe deux types de dialogue avec les modules, c'est pourquoi deux supports (sockets) de com- 

30 munication sont souhaitables pour gerer le dialogue noyau-module. Le premier type de dialogue se fait a I'initiative du 
noyau et concerne les mises a jour d'instances ou les demandes d'informations sur une base de gestion d'informations 
(MIB) ou les transmissions de notifications provenant d'un autre module. Le second type de dialogue se fait a I'initiative 
des modules et concerne les demandes d'informations ou les mises a jour d'instances de la base de gestion d'infor- 
mations (MIB). Le noyau gere deux listes de supports. La creation de support dans chacune de ces listes se fait 

35 dynamiquement lors de la connexion des modules. Pour le dialogue (snmp) avec i'administrateur le standard impose 
I'utilisation d'un seul support (socket). Le dialogue se fait sur le port 161/udp, mais I'utilisation d'un dispatcher de 
requetes necessite I'utilisation d'un autre port parametrable afin d'avoir la possibilite de faire fonctionner plusieurs 
agents (snmp) sur un meme equipement. Pour simplifier la gestion de communication avec les modules, une interface 
commune est definie sous forme de librairie. Par ailleurs, le noyau (N) possede une memoire cache (cache memory) 

40 (C) contenant toutes les informations resultant de ['administration d'un sous-reseau (RLE). Chaque module interroge 
le noyau pour initialiser ces parametres de fonctionnement. En outre, le noyau (N) gere une basede donnees contenant 
- toutes les instances de la base de gestion d'informations (MIB) du sous-reseau administre par le sous-administrateur 
(COACH). 

[0033] Le module de decouverte (MD) decouvre le sous reseau (RLE1 ) sur lequel est installele sous-administrateur 
45 (COACH 11). A Taide d'une table des masques d'adresse du protocole internet (IP, Internet Protocol), le module de 
decouverte (MD) determine les adresses (IP) des equipements (ET) que le sous : administrateur peut eventuellement 
administrer. Puis, le module de decouverte (MD) interroge successivement par groupe de paquet internet (PING Packet 
Internet Groper) unitaire tous les equipements possibles. Le PING est une interrogation standard que Ton peut utiliser 
pour savoir si une machine est connectee sur le reseau Internet, pour determiner la provenance d'un message ou pour 
50 verifier si un systeme est toujours en activite. Lorsqu'un equipement est visible sur le reseau, il repond au PING. 

[0034] Si un equipement est decouvert, le module de decouverte (MD) recherche son domaine. Chaque equipement 
appartient a un domaine, Le domaine de chaque equipement permet de definir des groupes d'indicateurs et de filtres 
d'alarme a injecter sur chacun des equipements et ceci, en fonction des agents presents sur ces equipements et done 
en fonction des roles depourvus a chaque equipement. 
55 [0035] Le domaine d'un equipement est defini selon la reponse ou non de I'equipement a un ensemble d'instances 
d'objets de la base de gestion d'informations (MIB snmp). Des la decouverte d'un nouvel equipement, une interrogation 
(polling) est effectuee sur un ensemble d'instances d'objets (snmp). Lorsqu'un equipement (ET) decouvert repond aux 
interrogations de toutes les instances d'objets definissant un domaine, on dit que I'equipement appartient a ce domaine. 
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Tous les equipements decouverts sont classes selon des domaines. Ces.domaines permettent de differencier ies 
differents types d'equipements et d'administrer differemment chacun des equipements selon son domaine. Un equi- 
pement peut appartenir a plusieurs domaines. 

[0036] Le domaine MIB2 pourrait, par exemple, etre defini par la r^ponse a ('instance "sysUpTimeO". Tous les equi- 
pements decouverts sont interroges sur cette instance. Ceux qui y repondent appartiennent au moins au domaine Ml B2. 
[0037] Enfin, lorsque le module de decouverte (MD) a decouvert un equipement et son domaine, il envoie une no- 
tification a un module de configuration des modeles (MCM) en lui indiquant I'adresse du protocole internet (IP) de 
I'equipement decouvert et le domaine auquel cet equipement appartient. Avantageusement, le module de decouverte 
(MD) envoie, de plus, ces memes informations au noyau (N) qui les stockera dans une base de donnees. 
[0038] Generalementrlorsqu'un systeme extstant est decouvert une seconde fois, son domaine n'est pas, a nouveau, 
recherche. Neanmoins, le domaine d'un systeme peut etre recherche en positionnant sur 'actif (ON) I'instance de la 
base de gestion d' informations (MIB) relative a la decouverte des domaines. Dans ce cas si, le domaine n'est pas le 
meme que le precedent, la base de donnees du noyau est automatiquement mise a jour et des notifications sont 
automatiquement envoyees au module de configuration des modeles (MCM). 

[0039] Lorsqu'un equipement precedemment decouvert ne repond plus a un PI NG unitaire, le modele de decouverte 
(MD) envoie une notification a un module (MCG) chien de garde (Watchdog) afin qu'il verifie si I'equipement a reellement 
disparu du reseau. 

[0040] Des sa connexion, |e module de decouverte (MD) interroge le noyau (N) afin de connaitre ses parametres 
d'initialisation: 

la periode entre deux decouvertes successives, - 
le nombre minimum de systemes a decouvrir, 

le masque du protocole internet (IP) determinant I'etendue du reseau a decouvrir. 

[0041] Le module de decouverte comporte des elements de configuration de base, un ensemble d'instances d'objets 
de la base de gestion d'information (MIB) a interroger et la liste des systemes decouverts ainsi que leurs domaines. 
[0042] L'annexe 7 presente un modele de configuration de la decouverte. L'annexe 8 presente les donnees dyna- 
miques de decouverte. 

[0043] Le module de filtrage d'alarmes (MFA) recoit les alarmes (traps) envoyees par les agents (snmp), implementes 
sur les equipements (ET) et filtre les alarmes a reemettre vers I'administrateur principal (AD). Des la reception d'une 
alarme, ce module tente de reconnaitre dans quel domaine appartient I'equipement (ET) qui a envoye cette alarme. 
Ce renseignement lui permettra de determiner le modele de filtre a appliquer a cette alarme. Un modele de filtre 
d'alarmes est defini par une description de I'alarme a reconnaltre (champs SNMP de description: Entreprise, generique, 
specif ique) et par un nombre maximal d'occurrence d'alarmes pendant une certain e periode avant lequel une autre 
alarme est emise. Le choix du modele de filtre se fait en fonction du domaine auquei I'equipement envoyant une alarme 
appartient. Lorsqu'une alarme n'est pas reconnue, elle est transmise a I'administrateur principal (AD). De plus, la 
premiere instance d'alarme recue est toujours emise vers I'administrateur principal (AD). Par exemple, pour un equi- 
pement appartenant au domaine "Imprim", c'est-a-dire une imprimante, un modele d'alarme indiquant "plus de papier 
dans I'imprimante" est defini. Ce modele est instancie sur toutes les imprimantes du sous-reseau. Le modele de filtre 
de cette alarme est decrit comme une alanine de niveau 0, envoye a I'administrateur (AD). Ainsi, si 1'un des agents 
des imprimantes emet cette alarme, le module de filtrage d'alarmes (MFA) ne transmettra aucune de ces alarmes a 
I'administrateur principal (AD). Si, ces memes imprimantes emettent une alarme de dysfonctionnement revelant un 
"probleme reseau" et que le modele de filtre de cette alarme est decrit comme etant de niveau 1 sur 50 en moins de 
■30 minutes, signifiant qu'il faut reemettre-une atarmeJorsque cinquante alarmes. ont ete recues en moins de trente 
minutes, le module de filtrage d'alarmes (MFA) reemettra pour chaque imprimante la premiere alarme recue, puis 1 
sur 50 dans une periode de 30 minutes. Si seulement deux alarmes arrivent a au moins trente minutes d'intervalle, 
elles seront toutes les deux transmises. 

[0044] Le module de filtrage d'alarmes (MFA) est aussi a I'ecoute du noyau (N). Ce dernier lui envoie des notifications 
de mise a jour de modele de filtre d'alarmes. Les donnees contenues dans le module de filtrage d'alarmes (MFA) sont 
la description des modeles et des informations sur les instanciations de ces modeles (date de la premiere instance 
d'alarme recue, nombre d'alarmes recues pendant la periode critique). 

[0045] En outre, 1'envoi d'alarmes peut etre archive dans un fichier sur le disque dur par J'emploi de la fonction "set" 
et I'administrateur peut le recuperer avec, par exemple, un protocole de transfer! de fichiers (FTP, File Transfer! Pro- 
tocol). Les informations ainsi archivees concernent la date, I'enterprise, le generique et le specrfique d'une alarme 
emise. Un envoi d'alarme peut, par exemple : etre trace sous cette forme: Nov 19 19:32 1997; 1 .3.6.1.4.1 .107.^ 44;6; 
1. Cette information doit etre interpreted sous cette forme : le 19 novembre 1997, a 19h32, une alarme d'enterprise 
1. 3.6.1. 4. 1.1 07.1 44 de type generique 6 et specifique 1 a ete emise vers I'administrateur. L'envoi d'alarmes peut aussi 
etre archive dans une table des masques d'alarmes. Avantageusement, I'ensemble des informations contenues dans 
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le message peut aussi etre archive. 

[0046] L'annexe 2 presente un modele de fiitre d'alarmes. L'annexe 3 pr6sente les donnees dynamiques d'un filtre 
d'alarmes. 

[0047] Le module de calcul d'indicateur (MCI) calcule des indicateurs sur les equipements (ET) a administrer. Un 
s indicateur est une equation dans laquelle des instances d'objets de gestion de base de d'informations (Ml B snmp) sont 
introduites. Ces instances d'objets sont obtenues par P interrogation (polling) sur les agents (snmp) fonctionnant sur 
chacun des systemes a administrer. Le resultat de cette equation est compare a une valeur seuil ne devant pas etre 
depassee un certain nombre de fois pendant un certain laps de temps. Lorsque la valeur seuil est depassee, un certain 
nombre de fois pendant un certain laps de temps, une alarme est emise vers I'administrateur principal (AD). 
10 . [0048] Prenons I'exemple d'un indicateur a instancier sur les equipements du domaine Ml B2 cornportant une periode 
d'interrogation de 60 secondes. Cet indicateur calcule Putilisation de la bande passante d'une carte de reseau quel- 
conque a I'ajde de ('equation: 



is 



(8*$- (illnOctets.1 + ifOutOctets.1) /if Speed. 1 



Cette equation sera calculee sur chacun des equipements du domaine MIB2 toutes les minutes. Si, sur !e systeme 
"A", le resultat excede la valeur 10 au moins deux fois en cinq minutes, une alarme sera envoyee a I'administrateur 
principal (AD). Et cette alarme sera percue par ce dernier comme provenant du systeme "A". 
20 [0049] Un indicateur comporte des operateurs simples tels que I'addition (+), la soustraction (-), la multiplication (*), 
la division (/) et des operateurs d'ensemble. Les operateurs d'ensemble permettent d'appliquer un operateur sur des 
series d'instances d'indicateurs. Ainsi, l'operateur: 

!SUM qui realise la somme d'une serie d'instances d'indicateurs, 
25 - !MOY qui realise une' moyenne d'une serie d'indicateurs, 

!MAX qui recherche la valeur maximum parmi une serie d'indicateurs, 
!MIN qui recherche la valeur minimum parmi une serie d'indicateurs. 

Attention, les operateurs d'ensemble sont appliques a des systemes et non au temps. L'annexe 9 nous decrit quelques 

30 exemples d'equations simples utilisant les operateurs d'ensemble. De plus, un indicateur peut egalement comprendre 
un operateur delta note $- et un operateur d'indirection temporel note &. L'operateur delta est defini tel que, a Pinstant 
t, $-(x) - x(t) - x(t-T) ou Pattribut x de valeur x(t- T) estrecueilli a Pinstant (t - T) et ou la valeur $-(x) donne la difference 
entre x(t) et x(t- T). $- (x) correspond a un delta et $t a un delta(t). L'operateur d'indirection temporel permet de reutiliser 
un calcul deja effectue sur un equipement. Le module de calcul des instances (MCI) interroge le noyau pour initialiser 

35 ces parametres de fonctionnement 

[0050] En fonctionnement, le module de configuration des modeles (MCM) notifie au module de calcul d'indicateurs 
(MCI) les modeles a instancier sur les equipements. Les donnees stockees dans le module de calcul d'indicateurs 
(MCI) sont les descriptions de modeles d'indicateurs (avec le nom du modele), les instanciations de chacun des indi- 
cateurs et des informations de fonctionnement comme, par exemple, le dernier resultat de ('instance, la date de la 

40 prochaine interrogation de Pin stance,... etc. 

[0051] Le resultat de I'instanciation d'indicateurs peut etre archive d'une part dans un fichier sur le disque dur a I'aide 
de Pemploi de la fonction "set". L'utilisateur selectionne nominativement les indicateurs qu'il veut journaliser (logger). 
Dans ce cas, I'administrateur peut le recuperer a Paide d'un protocole de transfert de fichiers (FTP). D'autre part, le 
resultat de I'instanciation d'indicateurs est aussi stocke dans une table d'indicateurs accessible directement par une 

45 requete SNMP. " _ " • ' 

[0052] Les informations concernant les indicateurs ainsi archives component la date, le modele de Pindicateur in- 
terroge, Padresse (IP) de Pequipement interroge et le resultat du calcul de Pindicateur. Un fichier archive peut, par 
exemple, etre trace sous cette forme : Nov 27 1 1 :44 1 997;3; 1 29. 1 84.59.7;271 .4268. Ce fichier doit etre interprets sous 
cette forme : le 27 novembre 1997, a 11h44, Pequipement 129.184.59.7 a ete interroge sur le modele 3 est le resultat 

so est 271.4268. 

[0053] Avantageusement, afin de limiter la taille du stockage des equations, les chatnes de caracteres correspondant 
aux instances interrogees sont stockees dans un tableau et representees par des identificateurs. 
[0054] Remarquons que toutes les fonctions de calcul d'equations, de description de seuils, de definition de pdriodes 
de calcul, de frequence maximale de depassement de seuil, de sens de comparaison du resultat sont entierement 
ss configurables a distance et dynamiquement via le protocole snmp. 

[0055] L'annexe 5 presente un modele d'indicateur. L'annexe 6 presente les donnees dynamiques d'indicateurs. 
[0056] Lorsqu'un equipement ne repond plus aux sollicitations des modules de decouvertes (MD) et de calcul d'in- 
dicateurs (MCI), le module (MCG) chien de garde (watchdog) verifie si cette equipement a reellement disparu. En effet, 
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75 



cet equipement n'a pas ete forcement supprime. Un equipement peut ne plus ne plus etre visible pendant un certain 
laps de temps en raison des aleas lies au trafic du reseau ou parce que le reseau local d'entreprise (RLE) est surcharge. 
Le role du module chien de garde (MCG) est de le verifier 

[0057] Quand, le module de decouverte (MD) ou le module de calcul d'indicateurs (MCI) previent le module chien 
5 de garde (MCG) de I'eventuelle disparition d'un equipement, le module de chien de garde (MCG) sollicite, a nouveau, 
cet equipement mais de maniere plus pressante. II envoie un message a I'equipement suppose disparu et attend une 
reponse pendant un temps tres long, il laisse beaucoup plus de temps a I'equipement pour repondre. Si I'equipement 
repond, le module chien de garde (MCG) ne signale rien et par defaut, les modules de decouverte (MD) et/ou le module 
de calcul d'indicateurs (MCI) supposent que i'equipement existe toujours. Si I'equipement ne repond pas, le module 
to chien de garde envoie un nouveau message en laissant a I'equipement suppose disparu un temps de reponse encore 
plus long. Apres un certain nombre d'envois de messages, si I'equipement suppose disparu n'a toujours pas repondu 
aux differents messages, le module chien de garde (MCG) emet une alarme en direction de I'administrateur principal 
(AD) lui indiquant la disparition de cet equipement. Cette alarme est simulee comme provenant de I'equipement disparu. 
Ceci permet une valorisation de reformation et une simplification de visualisation au niveau de I'administrateur prin- 
cipal. Le module chien de garde (MCG) envoie des notifications au module de decouverte (MD), au noyau (N) et au 
module de configuration des modeles (MCM) de maniere a ce que I'equipement disparu sort supprime de leurs bases 
de donnees. 

[0058] Lorsqu'un equipement n'a pas repondu a la sollicitation du module de calcul d'indicateurs (MCI), mais que 
I'equipement repond a ('interrogation du module chien de garde, il est possible que des agents (snmp) aient ete mo- 

20 difies. Une redecouverte du domaine de ce systeme est alors automat iquement demandee. 

[0059] Le module de securisation d'aiarmes (MSA) permet de securiser les alarmes envoyees par le sous-adminis- 
trateur (COACH) vers I'administrateur principal (AD). Ce module fonctionne seion un mecanisme client-serveur, le 
serveur du module de securisation d'aiarmes (sMSA) est attache a I'administrateur principal (AD) et le client du module 
de securisation d'aiarmes est attache au module de filtrage d'aiarmes (MFA). Lorsqu'une alarme est envoyee a t'ad- 

2B ministrateur, elle est toujours accompagnee d'un message d'envoi envoye par le client (cMSA) et destine au serveur 
(sMSA). La reception de ce message d'envoi par le serveur (sMSA) implique automatiquement que I'administrateur 
ait recu I'alarme accompagnant ce message. Lorsque le serveur (sMSA) receptionne le message d'envoi, il envoie au 
client (cMSA) un message de confirmation de reception. Des reception du message de confirmation de reception, le 
client (cMSA) enleve les instances d'aiarmes stockees dans le module de filtrage d'aiarmes (MFA). Lorsque, apres un 

30 temps determine par avance, le client (cMSA) n'a pas recu de message de confirmation de reception, il renvoie I'alarme 
accompagnee d'un nouveau message d'envoi a I'administrateur principal. Le client (cMSA) recommence cette opera- 
tion jusqu'a ce qu'il recoive un message de confirmation de reception. 

[0060] La confirmation d'aiarmes permet de garantir de maniere quasiment absolue la reception des alarmes par 
I'administrateur. Le fonctionnement global a encore ete ameliore par une fonction d'emission d'aiarmes en bloc. Le 
35 module de securisation d'aiarmes (MSA) a la possibility de ne pas envoyer pas instantanement les alarmes mais les 
archive puis les envoie, par paquet, a une frequence donnee. Les lignes de communication ne sont sollicitees que 
pendant cette periode. La frequence d'emission des alarmes est choisie lors du parametrage du module de securisation 
d'aiarmes. Ce principe est particulierement interessant pour les lignes du Reseau Numerique a Integration de Service 
(RNIS) (Integrated Services Digital Network, ISDN) pour lesquelles I'ouverture d'une ligne prend du temps, et la fer- 
meture s'effectue apres un delai. Avantageusement, pour augmenter encore la securisation de ces alarmes, la ligne 
est ouverte quelques secondes avant renvoi des alarmes. 

[0061] Le module de configuration de modeles (MCM) permet d'indiquer dynamiquement aux modules de calcul 
d'indicateurs (MCI) et de filtre d'aiarmes (MFA), les indicateurs et les modeles de filtrage d'aiarmes a appliquer sur 
chacun des equipements (ET) du sous-reseau. Lorsde la decouverte d'un equipement, le module de decouverte (MD) 
envoie une notification au module de configuration des modeles (MCM), lui indiquant I'adresse du protocole internet 
(adresse IP) de I'equipement decouvert, ainsi que le domaine auquel il appartient. Le module de configuration des 
modeles (MCM) notifie, alors, I'indicateur, au module de calcul d'indicateurs (MCI) et le modele de filtre, au module de 
filtrage d'aiarmes. 

[0062] Si , par exemple, un indicateur doit etre instance sur les systemes MIB2, pour tous les systemes decouverts, 
50 le module de configuration des modeles (MCM) va indiquer I'instanciation de cet indicateur au module de calcul d'in- 
dicateurs (MCI). 

[0063] Le module de configuration de modeles (MCM) comporte les correspondances entre les domaines et leurs 
modeles (de filtre et d'indicateur). 

[0064] Le module de configuration de modeles (MCM) est compost d'une partie ^initialisation, et d'une partie de 
55 m ise a jour en fonctionnement. Lors de I'initialisation, les descriptions d'indicateurs et de modeles de filtre existant 
dans ia base de donnees du noyau (N) sont detruites. Ces descriptions sont par la suite lues dans un fichier d'initiali- 
sation (confmod.ini). 

[0065] Un exemple d'un fichier de configuration (confmod.ini) contenant un indicateur est decrit en annexe 4. Un 
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indicateur est defini par differents champs: 



Champ 


Definition 


Type 


IND pour un modele d'INDicateurs 


Id 


Index d'indicateur (generation -automatique) 


Nom 


Nom de I'indicateur 


Domaine 


Regroupement d'equipements administres trouves 




par leur adresse en domaines identifiables par 5 




requetes "Get" envoyees par le sous-admin ist rate ur 




(COACH). Cela signifie qu'aujourd'hui, il existe au 




plus 5 identifiers d'objets (Oids) possibles pour 




definir un domaine 


Equation 


Equation de I'indicateur 


T polling 


Periode d'interrogation ou de construction de 




I'indicateur 


Seuil 


Seuil de decision pour remission d'une alarme 


Apparition 


Nombre d'apparitions de la valeur seuil apres 




laquelle il y a emission d'alarmes 


Periode 


Periode au-dela de laquelle le nombre 




d'apparitions des x valeurs de seuil est remis a 




i zero 


Sens de comparaison 


Sens de comparaison entre le seuil defini et le 




resultat de ('equation pour decrire un 




depassement. It peut etre >, <, =, ou != 


Booleen de Log de 


Ce champ permet de creer un historique (logguer) sur I'indicateur en phase de 


I'indicateur 


| journalisation 




| generaie, II prend la valeur "LOG" pour iogguer 




j I'indicateur ou "NLOG" pour ne jamais logguer 




j I'indicateur 



[0066] Un exemple d'un fichier de configuration (confmod.ini) contenant un modele de filtre d'alarmes est decrit en 
annexe 1 Un modele de filtre d'alarmes est defini par differents champs: 





Champ 


Definition 




Type 


FIL pour un modele de FILtre 


40 


id 


Index du modele de filtre (generation automatique) 




Nom 


Nom du filtre 




Domaine 


Regroupement des equipements administres trouves 
par leur adresse en domaines identifiable par 5 


45 




requetes "Get" envoyees par le sous-administrateur 




COACH 




Enterprise 


Champ "enterprise" de Talarme a filtrer 




Generic 


Champ "generique" de I'alarme a filtrer 




Specific 


Champ "specifique" de I'alarme a filtrer 


SO 


Apparition 


Nombre d'apparitions de I'alarme apres laquelle, il 
; y a reemission d'une alarme vers I'administrateur 


55 


Periode 


Periode au-dela de laquelle sans reception 
d'alarmes de ce type, le nombre d'apparition 
d'alarmes est remis a zero. 



[0067] Apres initialisation, le module de configuration des modeles (MCM) interroge le noyau afin de connaTtre tous 
les Equipements decouverts ainsi que leurs domaines. Puis, il envoie des notifications au module de filtrage d'alarmes 
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(MFA) et au module de calcul d'indicateurs (MCI), leur indiquant les modeles a instancier selon les adresses du pro- 
tocole internet (adresse IP) des equipements decouverts. 

[0068] En fonctionnement courant, le module de configuration des modeles (MCM) est a I'ecoute du support (socket) 
de communication du noyau et attend des changements. Ces changements peuvenl concerner soit I'ajout ou la sup- 
pression d'un equipement sur le reseau, soit des modifications d'indicateurs ou de modeles de filtre. 
[0069] D'autres modifications a la portee de I'homme de metier font egalement partie de I'esprit de I'invention. 
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ANNEXE 1 



# SECTION de description des filtres de traps 

10 ' 

# Format de la ligne de description 

^ # I Type I nom du trap I entreprise I Generic I Specific I limite en nb traps I periode I 

# 

20 # AXA/COACH/unix/trapFilters 
# 

FEL 1 alix-fs-nfull 2 Bull 1 18 6 4 1 60 
2s FEL 2 alix-fs-error 2 1.3.6. 1 .4. 1 .107. 1 14 6 5 100 6 

FTL 3 alix-uxLoginSession-setFailed 2 Bull. 1 18 6 33 3 30 

FIL 4 trap_essai_4 1.3.6.1.4.1 107.1446 7 3 10 
30 FEL 5 trap_essai_5 1 1.3.6.1.4.107.144 6 8 2 10 

FTL 6 alix-fs-nfull 2 Bull. 1 18 6 9 1 60 

FIL 7 alix-fs-error 2 Bull. 1 18 6 10 1 60 

35 

FTL 8 alix-uxLoginSession-setFailed 2 Bull. 1 18 6 1 1 3 30 
FIL 9 trap_essai_4 1 1.3. 6. 1.4.1. 107.144 6 12 3 10 
FIL 10 trap essai 5 1 1.3.6.1.4.1.107.1446 13 2 10 

40 ~ ~ 

FTL 11 alix-fs-nfull2Bull.ll8 6 14 1 60 

FTL 12alix_fs_error 2 Bull. 118 6 15 1 60 
4S FTL 1 3 alix-uxLoginSession-setFailed 2 Bull. 118 6 133 3 30 

FIL 14 trap_essai_4 1 1,3.6.1.4.1.107.144 6 17 3 10 

FTL 15 trap_essai_5 1 1.3.6.1.4.1.107:144 6 18 2 10 
so FEL 16 alix-fs-nfull 2 Bull. 118 6 19 1 60 

FEL 17 alix_fs_error 2 Bull. 1 1 8 6 20 1 60 

FEL 18 alix-uxLoginSession-SetFailed 2 Bull. 1 18 6 21 1 3 30 
ss FEL 19 trap_essai_4 1 1.3.6.1.4.1.107.144 6 212 3 10 
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FIL 20 trap_essai_5 1 1.3.6.1.4.1.107.144 6 213 2 10 
5 FIL 21 alixjs_nfull 2 Bull. 118 6 24 1 60 

FIL 22 alix-fs-error 2 Bull. 1 18 6 25 1 60 

FIL 23 alix-uxLoginSession-setFailed 2 Bull. 1 18 6 233 3 30 
io FIL 24 trap_essai_4 1 1.3.6.1.4.1.107.144 6 27 3 10 

FIL 25 trap_essai_ 5 1 1.3.6.1.4.1.107.144 6 28 2 10 

FIL 26 alix-fs-nfull 2 Bull. 118 6 29 1 60 
15 FIL 27 alix-fs-error 2 BuU. 1 18 6 30 1 60 . 

FIL 28 alix-uxLoginSession-setFailed 2 Bull. 118 6 311 3 30 

FIL 29 trap_essai_4 1 1.3.6.1.4.1.107.144 6 312 3 10 

20 

FIL 30 trap_essai_5 1 1.3.6.1.4.1.107.144 6 313 2 10 

25 
30 
35 
40 

45 .' 

SO 

55 
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5 



— Mo deles de fiitres 



10 



cfgFilterTable OBJECT-TYPE 

SYNTAX SEQUENCE OF CfgFilterEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table de configuration des modeles de fiitres." 
::= { CoachCfg2 } 



CfgFilterEntry OBJECT-TYPE 

SYNTAX CfgFilterEntry 

ACCESS not-accessible 
STATUS mandatory 

DESCRIPTION 

"Une entree (ligne) dans la table des modeles de fiitres." 

INDEX { cfgFilterld } 

::= { cfgFilterTable 1 } 



CfgFilterEntry ::= 
SEQUENCE { 
55 cfgFilterld 

INTEGER, 
cfgFLlterLabel 

OCTET STRING, 
40 cfgFilterDomain 

INTEGER, 
cfgFilterEnterprise 

OBJECT IDENTIFIER, 
4S cfgFilterGeneric 

INTEGER, 
cfgFilterspecific 

INTEGER, 
cfgFilterCptMax 
50 INTEGER, 

cfgFilterPeriodValid 
INTEGER 

} 
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cfgFilterld OBJECT-TYPE 
SYNTAX INTEGER 
5 ACCESS read-only 

STATUS mandatory 
DESCRIPTION 

"La valeur de cet attribut identifie de maniere unique une entree dans 
10 la table des modeles de filtres." 

::= { cfgFilterEntry 1 } 

cfgFilterLabel OBJECT-TYPE 
15 . SYNTAX OCTET STRING 

ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Description textuelle d'un modele de filtre." 
20 ::={ cfgFilterEntry 2 } 

cfgFilterDomain OBJECT-TYPE 
SYNTAX INTEGER 
25 ACCESS read-write 

STATUS mandatory 
DESCRIPTION 

"Identifiant du domaine auquel appartient le modele de filtre " 
30 {cfgFilterEntry 3 } 

cfgFilterEnterprise OBJECT-TYPE 
SYNTAX OCTET STRING 
35 ACCESS read-write 

STATUS mandatory 
DESCRIPTION 

"Object Identifier de Tentreprise du trap." 
::= { cfgFilterEntry 4 } 

40 

cfgFilterGeneric OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
45 STATUS mandatory 

DESCRIPTION 

"Numero generique du trap." 
::= { cfgFilterEntry 5 } 

50 

cfgFilterSpecific OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read- write 
STATUS mandatory 
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DESCRIPTION 

"Numero specifique du trap." 
: := { cfgFilterEntry 6 } 

cfgFilterCptMax OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Nombre de fois ou le trap doit etre recu durant <cfgFilterPeriodValid> 
pour qu'il soit transmis." 
{ cfgFilterEntry 7 } 

cfgFilterPeriodValid OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Periode (en secondes) durant laquelle le trap doit etre recu 

<cfgFilterCptMax> fois pour etre transmis." 
: := { cfgFilterEntry 8 } 
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ANNEXE 3 



— Donnees de filtres 



filterTable OBJECT-TYPE 

SYNTAX SEQUENCE OF FilterEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table associant un modele de filtre a une machine. " 
::= { CoachData 2 } 

filterEntry OBJECT- TYPE 
SYNTAX FilterEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Une entree (ligne dans la table des filtres. " 
INDEX { filterId,filterIpAddress } 
::= { filterTable 1 } 

FilterEntry ::= 
SEQUENCE { 
filterld 

INTEGER, 
filterlpAddress 

IpAddress 

} 

filterld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Identifiant du filtre (te meme que <cfgFilterId>), la valeur de cet 
attribut identifie de maniere unique avec <filterIpAddress> une entree 
dans la table des filtres. " 
::= { filterEntry 1 } 
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filterlpAddress OBJECT-TYPE 
SYNTAX IpAddress 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" Adresse IP de la machine emettrice du trap, la valeur de cet attribut 
identifie de maniere unique avec <filterld> une entree dans la table des 
filtres." 

::= { filterEntry 2 } 
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# SECTION de description des indicateurs 



10 



is 



20 



25 



30 



35 



40 



45 



50 



# type : 

# Id : 

# Nom : 

# Domaine : 

# Equation : 

# T polling : 

# Seuil : 

# Apparition 



HMD | FIL respectivement INDicateurs ou FILtre 
index d'indicateur (generation automatique) 
nom de l'indicateur 

regroupement de systemes manages trouves par leur 
adresse en domaines identifiables par 5 requetes get 
envoyees par COACH 

equation de I'indicateur 

periode de polling ou de construction de l'indicateur 
seuil de decision pour remission d f un trap 

nomfare d^pparitions de la valeur de seuil apres laquelle, 
il y a emission de traps 



sur quelle periode apparaissent les x valeurs de seuil 
sens de comparaison entre le seuil et le resultat 
indique si l'indicateur devra etre loggue ou non 



# Periode : 

# Sens de comparaison : 
#Log : 
# 

# Format de la ligne de description 

#1 type I Id I Nom I Domaine i Equation I T polling | seuil I x fois I en T secondes 

sens du test I log 

# 

# AXA/COACH/internet/indicators 
# 

# % d'utilisation de la bande passante sur Tinterface 
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20 



IND 1 ifUtilizationBandWith 2(((8*$(ifInOctets. 1 +ifOutOctets. 1 ))/$t)/ifSpeed. 1)* 1 00 
600 10 1 1200 > LOG 

# % d'utilisation de la bande passante sur le segment 

5 IND 2 IfUtilizationBandWith All 3 | SUM(ifUtilizationBandWith) 1210 10 1 3 3600 > 

LOG 

# Debit de rejection de paquets en entree et sortie sur le segment 

io IND 3 ifDiscards 2 S-(ifInDiscards. 1+ifOutDiscards. 1) 120 1 1 120 > LOG 

# Somme des debits de rejection de paquets en entree et sortie sur ie segment 
IND 4i£DiscardsAll 3 I SUM(ifDiscaxds) 320 3 I 320 > LOG 

75 

# Longueur de la file d'attente des paquets en sortie sur l'interface 
IND 5 coachlfOutQlen 2 ifOutQLen. 1 330 5 1 330 > LOG 

# Somme des Longueurs de la file d'attente des paquets en sortie sur toutes les interfaces 
du segment 

IND 6 coachlfOutQLenAll 3 I SUM(coacfalfOutQLen) 670 50 1 670 > LOG 

# Nombre de paquets retransmit sur l'interface 

25 IND 7 coachcpRetransSegs 2 tcpRetransSegs. 0 340 5 1 340 > LOG 

# Debit d'erreurs sur Tinterface 

END 8 ifErrors 2 ($(iflnErrors. 1+ifOutErrors. l)$t) 290 5 I 290 > LOG 

30 

# Debit d'erreurs sur le segment 

IND 9 ifErrorsSUM 3 ! SUM[(ifErrors) 620 2 1 620 > LOG 

# Debit moyen d'erreurs sur toutes les interfaces du segment 
IND 10 ifErTorsMOY 3 (!MOY(ifErrors)*100) 630 5 1 630 > LOG 

# Debit unicast sur ['interface en entree et en sortie 

IND 11 ifUcastPackets 2 (iflnUcastPkts.l-*-ifOutUcastPkts.l)$t 280 5 1 280 > LOG 

# Debit multicast sur l'interface en entree et en sortie 

IND 12 ifNUPackets 2 (iflnNUcastPkts.l+if^ 5 1 280 >NLOG 

45 # % d'erreurs sur l'interface par rapport au total des paquets emis ou re^us 

rND 13 ifErrorsRatio 2 (&i£Errors/(&if!nPackets+&ifOutPackets)) * 100 570 5 1570 > 
NLOG 
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SO 



# % moyen sur le segment des erreurs sur toutes les interfaces du segment 
IND 14i£ErrorsRatioLinkMOY 3 IMOY(ifErrorsRatio) 1220 5 1 1220 > LOG 
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#% Somme des percentages d'erreurs sur toutes les interfaces des liens 

IND 15 IfErrorsRatioLrnkSUM 3 !SUM(ifErrorsRatio) 1220 20 1 1220 > LOG 

t^Jl™ ^ W ^ " ™« pour caiculer 

IND 16 ipInputErrors 2$-(ipInHdrError S :o + ipInAddrErrors.O) 650 5 1 650 > LOG 

# % d'erreurs d'en-tete et d'adresse sur 1'interface 

IND 17 ipInputErrorsPercent 2 (^ipInputErrors/CHipInDelivers ^WnoO 650 5 1 650 

#Somme des percentages d W S d'en-tete et d'adresse sur 1'interface 

rND 18 .plnputErrorsPercentOnLink 3 !SUM(ipInputErrorsPercent) 300 5 1 300 > LOG 

# lndisponibilite d\me machine 

IND 19 NoDisponibility 2-$t/($-( S y S UpTin,e.O)) 100 1 1 300 > LOG 

I^Zk^V^ 6 P0Uf renSemble des mac ^ *> segment 
IND20NoD,spombuityOnLmk3 !SUM(NoDisponibiity) 150 100 1 300>LOG 

# 21/10/97 20: 17 ficfaier : CONFMOD.DOC#version DRAFT 
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ANNEXES 



Coach-MIB DEFINITIONS ::= BEGIN 



bull 

gam 

Coach 

CoachCfg 

CoachData 



OBJECT IDENTIFIER ::={ enterprises 107 } 
OBJECT IDENTIFIER ::={ bull 146 } 



OBJECT IDENTIFIER ::={ gam 1 } 



OBJECT IDENTIFIER ::={ Coach 1 } 



OBJECT IDENTIFIER : :={ Coach 2 } 



CoachSystem OBJECT IDENTIFIER ::={ Coach 3 } 



— Configuration de Coach 



-- Modeles d'indicateurs 



cfglndicatorTable OBJECT-TYPE 

SYNTAX SEQUENCE OF CfglndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table de configuration des modeles d'indicateurs." 
{ CoachCfg 1 } 

CfglndicatorEntry OBJECT-TYPE 
SYNTAX CfglndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Une entree (ligne) dans la table des modeles d'indicateurs. " 
INDEX { cfglndicatorld } 
::= { cfglndicatorTable 1 } 
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ComparaisonType ::= INTEGER {equal(0),less(l),greater(2)} 



10 



CfglndicatorEntry 
SEQUENCE { 

cfglndicatorld - 

INTEGER, 
cfglndicatorLabel 

OCTET STRING, 
cfglndicatorDomain 
INTEGER, 

1$ cfglndicatorEquation 

OCTET STRING, 
cfglndicatorPeriodPolling 

INTEGER, 
cfglndicatorThreeshold 

INTEGER, 
cfglndicatorCptMax 

INTEGER, 
cfglndicatorPeriodValid 
2s INTEGER, 
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cfglndicatorComparaison 
ComparaisonType 

} 

cfglndicatorld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"La valeur de cet attribut identifie de maniere unique une entree dans 
la table des modeles d'indicateurs." 
::= { CfglndicatorEntry 1 } 

cfglndicatorLabel OBJECT-TYPE 
SYNTAX OCTET STRING 
ACCESS read-write 
STATUS mandatory 

DESCRIPTION . * ~ - - - : - ; 

"Description textuelle d'un modele d'indicateur. " 
: := { CfglndicatorEntry 2 } 

cfglndicatorDomain OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
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DESCRIPTION 

"Identifiant du domaine auquel appartient le modele d'indicateur." 
: := { cfglndicatorEntry 3 } 

cfglndicatorEquation OBJECT-TYPE 
SYNTAX OCTET STRING 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Equation arithmetique decrivant le modele d'indicateur." 
: := { cfglndicatorEntry 4 } 

cfglndicatorPeriodPolling OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Periode (en secondes) a laquelle Tindicateur va etre calcule." 
::= { cfglndicatorEntry 5 } 

cfglndicatorThreeshold OBJECT-TYPE 
S YNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Seuil que doit depasser Tindicateur <cfgIndicatorCptMax> fois durant 
<cfgIndicatorPeriodValid> pour qu'une alarme soit envoyee." 
::= { cfglndicatorEntry 6 } 

cfglndicatorCptMax OBJECT-TYPE 
SYN TAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Nombre de fois ou Tindicateur doit depasser <cfgIndicatorThreeshold> 
durant <cfgIndicatorPeriodValid> pour qu*une alarme soit envoyee." 
{ cfglndicatorEntry 7 } 

cfglndicatorPeriodValid OBJECT-TYPE 

SYNTAX INTEGER 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 

"Periode (en secondes) durant laquelle l'indicateur doit depasser 
<cfgIndicatorCptMax> fois <cfgIndicatorThreeshold> pour qu*une alarme 
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soit envoyee." 
: := { cfglndicatorEntry 8 } 

cfglndicatorComparaison OBJECT- TYPE 
SYNTAX ComparaisonType 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Type de comparaison entre le seuil <cfgIndicatorThreeshold> 

le resultat de Tequation <indicatorResult> fl 
::= { cfglndicatorEntry 9 } 
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ANNEXE 6 



-- Donnees d'indicateurs 



indicatorTable OBJECT-TYPE 

SYNTAX SEQUENCE OF IndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

"Table de resultats de calculs d'indicateurs." 
::= { CoachData 1 } 

indicatorEntry OBJECT-TYPE 
SYNTAX IndicatorEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRJPTION 

"Une entree (ligne) dans la table des indicateurs." 
INDEX { indicatorld, indicatorlp Address } 
{ indicatorTable 1 } 

IndicatorEntry ::= 
SEQUENCE { 
indicatorld 

INTEGER, 
indicatorlpAddress 
IpAddress, 
indicatorResult 

INTEGER 

} 

indicatorld OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Identifiant de l'indicateur (le meme que <cfgIndicatorId>), la valeur 
de cet attribut identifie de maniere unique avec <indicator!pAddress> 
une entree dans la table des indicateurs." 
::= { indicatorEntry 1 } 

indicatorlpAddress OBJECT-TYPE 
SYNTAX IpAddress 
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ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" Adresse IP de la machine sur lequel l'indicateur est calcule, la valeur 
de cet attribut identifie de maniere unique avec <indicatorId> une 
entree dans la table des Lndicateurs." 
; := { indicatorEntry 2 } 

indicatorResult OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"Resultat du calcul de Tindicateur." 
: := { indicatorEntry 3 } 
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ANNEXE 7 



— Configuration de la decouverte 



cfgDiscovery OBJECT IDENT (FER : : = { CoachCfg 4 } 

cfgDiscoverPeriod OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Periode (en secondes) a laquelle une decouverte est declenchee." 
::= { cfgDiscovery l } 



cfgDiscoverPeriodlCMP OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Periode (en secondes) de TICMP renforce." 
: := { cfgDiscovery 2 } 



cfgDiscoverBroadcast OBJECT-TYPE 
SYNTAX Ip Address 
ACCESS read-wnte 
STATUS mandatory 
DESCRIPTION 

"Adresse broadcast du sous-reseau." 
: := { cfgDiscovery 3 } 



cfgDiscoverDomainAtNextTime OBJECT-TYPE 
SYNTAX INTEGER { 

yes(i), 

no (2) 

} 

ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Redecouverte ou non des domaines au prochain Discovery." 
::= { cfgDiscovery 4 } 
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cfgDiscoverMaxDisc OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
w STATUS mandatory 

DESCRIPTION 

"Nombre maximum de mauvaises decouvertes." 
: = { cfgDiscovery 5 } 

15 

cfgDiscoverMaxICMP OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read- write 
20 STATUS mandatory 

DESCRIPTION 

"Nombre maximum de mauvaises reponses ICMP. 
: := { cfgDiscovery 6 } 

25 

cfgDiscoverMinMachine OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-write 
30 STATUS mandatory 

DESCRIPTION 

"Nombre minimum de machines sur le sous-reseau 
::- { cfgDiscovery 7 } 

35 

cfgDiscoverTimeOut OBJECT-TYPE 
SYNTAX INTEGER 
40 ACCESS read-write 

STATUS mandatory 
DESCRIPTION 

"Time_out de renvoi ICMP." 
::= { cfgDiscovery 8 } 

45 ' 



cfgDiscoverTimeOutlCMP OBJECT-TYPE 
SYNTAX INTEGER { 
yes (I), 
no (2) 

} 

ACCESS read-write 
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STATUS mandatory 
DESCRIPTION 

"Politique ICMP renforce lors de depassement de time_out." 
::= { cfgDiscovery 9 } 
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ANNEXE 8 

5 

— Donnees de decouverte 



fo discoverTabie OBJECT- TYPE 

SYNTAX SEQUENCE OF DiscoverEntry 
ACCESS not-accessible 
STATUS mandatory 

1S DESCRIPTION 

"Table de decouverte des machines gerees par Coach " 
"= { CoachData 3 } 

discoverEntry OBJECT-TYPE 
*> SYNTAX DiscoverEntry 

ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

2 5 " Une entree dans la table de decouverte " 

INDEX { discoverlpAddress } 
::= { discoverTabie 1 } 



30 

DiscoverEntry :.- 
SEQUENCE { 

discoverlpAddress 
IpAddress, 
discoverDomainld 
INTEGER 

} 
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discoverlpAddress OBJECT-TYPE 
SYNTAX Ip Address 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 

"Adresse IP de la machine, la valeur de cet attribut indentifie de 
maniere unique une entree dans la table de decouverte " 
: := { discoverEntry 1 } 

discoverDomainld OBJECT- TYPE 
SYNTAX INTEGER 
ACCESS read-write 
STATUS mandatory 
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DESCRIPTION 

"Identifiant du doraaine auquel appartient la machine." 
{ discoverEntry 2 } 
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X1 = !SUM (A) 


La somme X1 est realisee sur 


5 




toutes les instances A calculees 






par COACH On obtipnt • 






X1 =A1 +A2+A3+A4 


10 


X2= !MOY(A)- !MOY(B)+ !SUM(C) 


On obtient : 




X2= (A1+A2+A3+A4V4 + 






(B 1 +B2+B3+B4)/4 + 






(C1+C2+C3+C4) 


15 


X3 = »MOY(A)-IMOY(B) 


On obtient 






X3 = (A1 +A2+A3+A4)/4 - 






(B1+B2+B3+B4)/4 




X4 = !MAX(C) 


On obtient la valeur maximale 


20 




des valeurs des indieatpnrQ r* 






sur toutes les machinpc cur 






lesquelles cet indicateur est 






instance. 


25 




X4 = MAX5C1, C2, C3, C4) 




X5 = !MIN(C) 


On obtient la valeur minimale 






des valeurs des indicateurs C 






sur toutes les machines sur 


30 




lesquelles cet indicateur est 






instancie. 




X5 = MIN(CI, C2, C3, C4) 
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Revindications 
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nistrateur (COACH) srtue dans larbre de contenance entre un administrateur principal (AD) et les eauioements 

y differenta ; modules qui commumquent entre eux et avec un administrateur principal (AD) par I'in- 
Zf 1 n ° yaU (N)> l6S m ° dUleS interro 9 ea "t les equipements du sous-reseau et recevant ?es alarm es 
p1usiu S rs P Lp:s a : 9en,S ^ ^ du — ^ le pnc^Z^SgZZ 

" £u^SsL P u endSnt ' aqUel,e Un mbdUle ^ d6C ° UV6rte ( ^ D) interr ° 9e ,OUS leS «*«P*n-nto (ET) possibles du 

" .roSTsNMPr e de d ° maine P " ' e modu,a de d6couverte (MD >' lors ^ un ^p—< -Pond * rm- 

" des" ^KSSJfSS 16 Th ^ d ' COUVerte (MD) 6nVOie Une n ° tification * un module d * configuration 
ZSSZ^^ST ' 3dreSSe ,ntemet ( ' P) ^ ,,6aUipemen ' d6cOUV6rt 61 * -P- 9 , requi- 

' d?ndfcruHcn T^ZTT ^ COnf t rati ° n d6S m ° d&leS (MCM > notifie a un ^ ca.cu. 

Z^Th fi V °' " nd,cateur a inst anc.er sur I'equipement et a un module de firtrage d'alarmes (MFA) le 
modele de fittre a instancier sur I'equipement. uvir«> le 

2. Procede d'administration d'un reseau et d'un systeme selon la revendication 1, caracterise en ce au'a chaaup 
nouvelle etape de decouverte des equipements du sous-reseau, le module de decouveSe (MD) me^ jouMes 
bases de donnees du noyau (N) et du module de configuration des modeles (MCM) contenant la iTste des^i 
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pements et de leurs domaines. 

Proc6de d'administration d'un reseau et d'un systeme selon la revendication 1 , caracterise en ce que toutes les 
alarmes emises par les difterents modules sont envoyees a I'administrateur principal (AD) via le module de secu- 
risation d'alarmes (MSA), ladite alarme etant accompagnee d'un message d'envoi destine au serveur du module 
de securisation d'alarmes (sMSA). 

Procede d'administration d'un reseau et d'un systeme selon la revendication 3, caracterise" en ce qu'il est compose : 

d'une etape de reception de i'alarme par I'administrateur principal (AD) et de reception dudit message d'envoi 
par le serveur du module de securisation d'alarmes (sMSA)., 

d'une etape d'envoi d'un message de confirmation de reception par le serveur du module de securisation 
d'alarmes (sMSA) au client du module de securisation d'alarmes (cMSA), 

d'une etape de reception du message de confirmation de reception par le client du module de securisation 
d'alarmes (cMSA), 

d'une etape de mise a jour des instances d'alarmes stockees dans le module de filtrage d'alarmes (MFA). 

Procede d'administration d'un reseau et d'un systeme selon la revendication 1 . caracterise en ce lorsque le client 
du module de confirmation d'alarmes (MCA) n'a pas recu le message de confirmation de reception, il renvoie, 
apres un temps determine, I'alarme a I'administrateur principal (AD), I'alarme 6tant accompagnee d'un message 
d'envoi destine au serveur du module de securisation d'alarmes (sMSA). 

Procede d'administration d'un reseau et d'un systeme selon la revendication 1, caracterise en ce que lorsque le 
module de calcul d'indicateurs (MCI) ou le module de decouverte (MD) n'obtient pas de reponse a une requete 
envoyee a un equipement du sous-reseau, le module de calcul d'indicateurs (MCI) ou le module de decouverte 
(MD) envoie un message a un module chien de garde (MCG), le module chien de garde (MCG) interrogeant 
I'equipement suppose disparu et attendant de maniere plus longue, une reponse. 

Procede d'administration d'un reseau et d'un systeme selon la revendication 6, caracterise en ce que lorsque, 
apres un temps determine, le module chien de garde (MCG) n'obtient pas de reponse de I'equipement suppose 
disparu, Vquipement est supprime de la base de donnees du noyau (N), de la base de donnees du module de 
decouverte (MD) et de la base de donnees du module de configuration des domaines (MCM), le module chien de 
garde (MCG) envoyant une alarme a I'administrateur principal (AD), lui indiquant la disparition de I'equipement, 
I'alarme etant percue par I'administrateur comme provenant de I'equipement a travers le module de securisation 
et envoyee en utilisant le module de securisation. 

8. Procede d'administration d'un reseau et d'un systeme selon la revendication 6, caracterise en ce que lorsque le 
module chien de garde (MCG) obtient une reponse de I'equipement suppose disparu, il demande la redecouverte 
des domaines si la demande a ete emise par le module de calcu! d'indtcateur. 

40 

9. Systeme d'administration, d'un reseau et d'un systeme par un admin istrateur principal communiquant avec des 
equipements (ET) a travers un reseau grande distance (WAN) et des reseaux locaux d'entreprises (RLE) carac- 
terise en ce qu'il comprend au moins un sous-administrateur (COACH) localise sur le reseau local d'entreprise 
(RLE) et administre par I'administrateur principal (AD), le sous-administrateur (COACH) comportant des moyens 

45 d'interroger les equipements du reseau local d'entreprise (RLE), de filtrer et de stocker les alarmes Ianc6es par 

les agents (snmp) fonctionnant sur les equipements du reseau, des moyens de securtser les alarmes envoyees 
a I'administrateur principal (AD) et un moyen de dialogue avec I'administrateur principal et entre les difterents 
moyens. 

so 10. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que le moyen 
de dialogue est constitue d'un noyau (N) dialoguant avec I'administrateur principal (AD) et permettant le dialogue 
entre les differents modules composant ledit systeme, 

11. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que les moyens 
ss d'interroger les equipements du reseau local d'entreprise (RLE), de filtrer et de stocker les alarmes lancees par 

les agents (snmp) fonctionnant sur les equipements du reseau sont constitues 

d'un module de decouverte (MD) d6couvrant les equipements (ET) du sous-reseau a administrer et classant 



3. 

5 

4. 

10 
15 

5. 

20 

6. 

25 

7. 

30 



33 



BNSDOCID: <EP 0951 155A1_I_> 



EP0 951 155 A1 



10 



15 



20 



25 



30 



35 



40 



45 



SO 



55 



SS^tSir.T T H° m H aineS 6n f0rCSi0n d8S ,ypeS d " a9ents <** y so * Ce module de 

Z Ztr W dacouverte de Tadministrateur central, par une precision accrue, une c2 
couverte plus rapide et une economie considerable en band© passante 
- d'un module de configuration de modeles (MCM) comportant des modeles de filtre d'alarmes et des indicator* 

pou, un doma.ne do„„ e , tes d,es a,a™„ MlMteM* 4M rWmlse8 „„ s ^ 

module ch,en de garde (MCG) envoie une alarme a Tadministrateur principal (AD) qui sera peSe oaf ce 
dernier comme provenant de requipement disparu l™> qui sera percue par ce 

' Srr^. 0 ?"' 6 de ^ 6curisation d'alarmes (MSA) fonctionnant selon le mocanisme client-ser^eur le client fcMSAl 
sM<S> T I™"' a ' arme k K*™""'*™. attendant un message de confirmation du seneur 
(sMSA) localise sur radmmistrateur principal (AD), ledi, serveur (sMSA), apres reception S message tfln 

au re m V e °H U " messa 9* de C ° nfirmation de r *^n au client ,oM8A), le client renvoyalTiTme 
iTp^^ — » — — • " — • - confirm^ de 



BNSDOCID: <EP 0951 155A1_L> 



34 



EP 0 951 155 A1 

noyau comportant au moins deux supports (sockets) de communication et une interface commune de gestion de 
la communication avec les modules. 

21. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce que les para- 
s metres d'initialisation du module de decouverte (MD) component la periode espacant deux decouvertes, le nombre 

minimum de systemes a decouvrir et le masque du protocole internet (IP) determinant I'etendue du reseau a 
decouvrir. 

22. Systeme d'administration d'un reseau et d'un systeme selon la revendication 9, caracterise en ce qu'un equipement 
io (ET) decouvert est classe dans un ou plusieurs domaines en fonction de ses reponses aux interrogations effec- 

tuees surchaque ensemble d'instances d'objets de la base de gestion d'intormations (MIB) definissant un domaine. 
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